Method and system for user authentication in a digital communication system

ABSTRACT

A method and a system for authentication and synchronization is disclosed. The user provides a first one time code (OTC) to the authentication manager. If this OTC is within a small access window, the user is directly authenticated and granted access to the system. If the provided OTC is outside the small window but within a big window, the authentication manager saves the first OTC, and a second OTC is required from the user. If the new, second OTC and the first OTC are in sequence, the end user will be authenticated, and admitted access to the system and the requested service.

FIELD OF THE INVENTION

The present invention relates to a method and a system forauthentication in digital communication systems.

BACKGROUND OF THE INVENTION

The need for secure electronic transactions and access to remoteservices involving a user and a transaction system such as an Internetbased shopping site, Internet banking or an automatic teller machine(ATM) at a bank, has increased dramatically during recent years. A majorquestion relating to secure transactions is that of authentication ofthe user to the system. That is, how to identify a user as being theowner of, e.g., a bank account from which the user is to withdraw moneyfrom when using an ATM or Internet banking services.

A well-established method of authenticating users in such systems isthat of providing the user with an electronically readable devicecontaining information about the user and his account. Such cards arecommon and contain magnetically stored information. In order to allowthe user to use his card in an ATM, the issuer (e.g. the bank) hasprovided the user with a secret code to be supplied to the ATM whenusing the card. The code is used to “unlock” the card for use by theuser every time the user makes use of his card.

However, a drawback of such a method is that one and the same code isused every time a user authenticates with a system. This increases therisk of unauthorized use of the card if the user loses the card.

To this end, solutions have been developed using different codes fromoccasion to occasion, so called one time codes (OTCs). Such OTCs couldbe provided to the user by means of a sequence of codes to be used onetime each, and perhaps in a pre-determined order. Alternatively, theOTCs could be generated by means of portable code-generating devices, inwhich a new code is generated each time it is used, based onpersonalizing information provided by the user, such as a personalPIN-code. Such devices are generally of two types. A first type isspecifically developed gadgets with entering means such as a keyboard, adisplay, a processor for generating the code, etc. A second type relatesto so called smart cards or integrated circuit card (ICC), i.e. cardsprovided with a chip. For example, the document WO 02/01325 of the sameapplicant discloses such an authentication system using OTCs.

However, a problem in using OTCs is the problem of synchronizing thecode generation/selection process at the user side and in theauthentication manager, respectively. In case the processes areunsynchronized, the user will not be authenticated and authorized toaccess the required services or the like, even though a correct OTC wasentered. Synchronization could be achieved by keeping and updatingsynchronization data, such as a sequence number, a time value or thelike, in the same way at both user side and the authentication managerside. However, the synchronization data could easily becomeunsynchronized, for example due to manual errors, failed authenticationattempts, different clock rates, etc.

Attempts have been made in the past to alleviate this problem. Forexample, several acceptable OTC could be generated or selected at theauthentication manager, e.g. corresponding to a sequence ofsynchronization data. However, hereby the security level decreases, andthe problem is only partly solved, since the sequence, or window, ofacceptable OTCs may still not be enough to handle the occurredunsynchronization.

Another known solutions attempts to restore the synchronization.However, these known solutions are generally very cumbersome and tediousfor the user, and may also imply a security hazard.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide animproved method and system for user authentication, which is easier andfaster to use and/or is more secure.

This object is achieved with a method and a system according to theappended claims.

According to one aspect of the invention, a method is provided forauthenticating a user in a digital communication system, said systemcomprising at least one input device providing a user interface to thesystem, an authentication manager for authenticating the user to thesystem and a communication network connecting said input device and saidauthentication manager. The method comprises the steps:

-   -   receiving identification information about the user at said        authentication manager from said input device;    -   receiving an one time code (OTC) at said authentication manager        from said input device;    -   identifying, based on said identification information, a        sequence of verification OTCs associated with said user;    -   choosing at least one of the verification OTCs of said sequence        to be the most probable for authentication; and    -   comparing the chosen verification OTC and the OTC received from        the input device, and in case of a match authenticating the user        to the system; and in case of a non-match:    -   requiring, at least once, a new OTC from the user;    -   searching at least a part of the remaining sequence of        verification OTCs for verification OTCs in sequence matching the        OTCs received from the user; and    -   in case of a second match authenticating the user to the system.

According to this method, a very smooth, efficient but still secureauthentication process is provided. The first OTC provided by the useris verified against a small access window, comprising one or severalmost probable verification OTCs held by the authentication manager.Typically the small access window comprises four OTCs. In most cases,the synchronization deviation would be within this tolerance, wherebythe user would be unaffected by this deviation. In fact, this slightsynchronization deviation would be totally unnoticeable for the user.The deterioration in the security level of the system due to the size ofthis small access window is for normal applications insignificant. Incase the OTC provided by the user is outside the small access window,the OTC is normally either erroneous, or due to a slightly largersynchronization offset. This last case is handled in a very efficientway by the request of a further OTC. By checking the sequential relationbetween the first and second OTC, verification could be made with a veryhigh degree of security, while minimizing the required user interaction.Hereby, the process becomes very efficient, fast and easy to use, and atthe same time, the security level is not significantly deteriorated.

In one embodiment, the OTC from the input device is generated by meansof a OTC generation unit. E.g. the generation units is adapted togenerate the OTC based on input provided by a smart card held by theuser.

Preferably, the OTC generation unit calculates the OTC based onsynchronization data, such as a sequence number or a time value. In thatcase, the step of choosing the most probable one of the verificationOTCs could be made based on verification synchronization data held bythe authentication manager.

Thereafter, in case of a second match authenticating the user to thesystem, the verification synchronization data could be updated inaccordance with the identified matching verification OTCs.

The step of identifying a sequence of verification OTCs associated withsaid user could comprise the step of calculating a sequence of OTCs.

Alternatively, the step of identifying a sequence of verification OTCsassociated with said user could comprise the step of retrieving asequence of pre-stored OTCs.

The OTCs are preferably non-recurring strings of characters.

Further, the identification information could comprise an identificationcode associated with the user.

Still further, at least part of the communication between the inputdevice and the authentication manager could be encrypted.

According to another aspect of the invention, a correspondingauthentication system is provided for authenticating a user in a digitalcommunication system, the communication system comprising at least oneinput device providing a user interface to the system and anauthentication manager for authenticating the user to the system and acommunication network connecting said input device and saidauthentication manager. The system comprises:

-   -   means for receiving identification information about the user at        said authentication manager from said input device;    -   means for receiving an one time code (OTC) at said        authentication manager from said input device;    -   means for identifying, based on said identification information,        a sequence of verification OTCs associated with said user;    -   means for choosing at least one of the verification OTCs of said        sequence to be the most probable for authentication; and    -   means for comparing the chosen verification OTC and the OTC        received from the input device, and in case of a match        authenticating the user to the system;    -   means for requiring a second OTC from the user;    -   means for searching at least a part of the remaining sequence of        verification OTCs for verification OTCs in sequence matching the        OTCs received from the user; and    -   in case of a second match authenticating the user to the system.

Further scope of the applicability of the present invention will becomeapparent from the detailed description given hereinafter. However, itshould be understood that the detailed description and specificexamples, while indicating preferred embodiments of the invention, aregiven by way of illustration only, since various changes andmodifications within the spirit and scope of the invention will becomeapparent to those skilled in the art from this detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

For exemplifying purposes, the invention will be described in closerdetail in the following with reference to embodiments thereofillustrated in the attached drawings, wherein:

FIG. 1 is a schematic system overview of a system according to anembodiment of the invention;

FIG. 2 is a schematic flow chart illustrating an authentication processaccording to an embodiment of the invention; and

FIG. 3 is a schematic flow chart illustrating an authentication processaccording to a second embodiment of the invention.

DESCRIPTION OF PREFERRED EMBODIMENTS

The invention will now be described more thoroughly by way of example.

With reference to FIG. 1, the invention generally relates to anauthentication in a digital communication system. The system comprisesat least one input device 1, and preferably several input devices. Theinput device could be any device which provides a digital networkinterface for user, such as a general purpose computer, an ATM, acellular telephone or the like. Further, the system comprises at leastone authentication manager 2 for authenticating the user to the system.The authentication manager could be arranged as a server on the network,and could either be integrated with a service provider 3 for whichauthenticated is required, or be connected to such a service provider inany suitable way. Accordingly, the authentication manager and theservice provider may be separate functional units in one computer orfunctional units in different computers. The setup of the serviceprovider and connection between the service provider and theauthentication manager are known per se and will not be furtherdiscussed in this application. For example, the setup could be arrangedas is described in WO 02/01325 of the same applicant, said documenthereby incorporated by reference.

The service provider could be any type of remote services requireingAuthentication and involving a user and a transaction system such as anInternet based shopping site, Internet banking or an automatic tellermachine (ATM) at a bank.

The system further comprises a digital network 4 connecting the inputdevice and the authentication manager. For example, the network could bea wide area network (WAN), such as the Internet.

The authentication and synchronization process according to anembodiment of the invention will now be described with reference to FIG.2. The user first enters identification information to theauthentication manager through the input device, step S1. Theidentification information could be a identification code, a password,or any other type of information making it possible to identifiy theuser.

Further, the user retrieves a one time code (OTC), step S2. As alreadydiscussed, such OTCs could be provided to the user by means of asequence of codes to be used one time each, and perhaps in apre-determined order. However, preferably the OTCs are generated bymeans of a OTC generation unit, in which a new code is generated eachtime it is used, based on personalizing information provided by theuser, such as a personal PIN-code. However, the personalizinginformation may also be provided in other ways, as is obvious forsomeone skilled in the art. For example, the personalizing informationmay be provided automatically by entering e.g. a SIM-card or a smartcard dedicated to the user into the OTC generation unit. In case suchpersonal cards are used, the entry of an additional PIN-code may besuperfluous. Such an OTC generation unit could be a specificallydeveloped device with entering means such as a keyboard, a display, aprocessor for generating the code, etc. Alternatively, the device couldcomprise a reader for so called smart cards or integrated circuit card(ICC), i.e. cards provided with a chip. The reader is capable of readingout information from the card, and together the arrangement generates,e.g. as a response to a signal from the reader, a one-timeidentification code that could be used by the user to authenticatehimself when making transactions via a digital network. The OTCgeneration unit is preferably portable an not connected to thecommunication network. The OTCs are preferably non-recurring strings ofcharacters. The OTC generation unit could either be a unit dedicatedonly for OTC generation, or be integrated in e.g. a PDA or a mobilephone.

It is further preferred that the OTC generation unit calculates the OTCbased on synchronization data, such as a sequence number or a timevalue, said synchronization data being automatically incremented and/orupdated each time an OTC is generated, at regular time intervals, or anyother regularly occurring event.

The identification information and the OTC as entered to the inputdevice is then forwarded through the communication network to theauthentication manager, step S3.

The authentication manager makes a preliminary identification based onthe identification information, e.g. by matching the information with auser information database. Based on said preliminary identification, asequence of verification OTCs associated with said user is identified inthe authentication manager, step S4. This sequence is in thisapplication generally referred to as “the big access window” or simplythe “big window”. The sequence could be a pre-stored set ofpredetermined OTCs or be generated based on verification synchronizationdata held by the authentication manager, depending on the OTC generationprocess used at the user side. The sequence should comprise at least twoOTCs, and preferably more than five, and most preferably at least 10. Incase of OTC generation with sequence numbers, the sequence couldcomprise OTCs based on the currently held sequence numbers and a numberof following sequence numbers.

One or several of the OTCs in the verification OTC sequence are thenchosen as the most probable, i.e. what is in this application referredto as “the small access window” or simply the “small window”. Forexample, four OTCs could be chosen. The first OTC in the sequence isnormally chosen as the most probable, and, further, the most probableOTC is normally the one based on the latest updated synchronizationdata. In case several most probable verification OTCs are used, the mostprobable of the remaining OTCs are added until a predetermined number ofOTCs are obtained. In a preferred embodiment 2-5 most probable OTCs arechosen as the small access window, and most preferably about four. Incase OTC generation with sequence numbers is used, the most probable OTCis normally the one based on the latest updated sequence number, thesecond most probable the next sequence number after the latest updatedsequence number, the third most probable the second sequence numberafter the latest updated sequence number, and so on.

By using a small access window instead of just one chosen OTC, thesecurity level is slightly decreased, but on the other hand, minorsynchronization deviations are accepted without the user even noticingit.

The chosen verification OTC, i.e. the small window, and the OTC receivedfrom the input device are then compared, step S5, and in case of amatch, step S6, the user is authenticated to the system, and admittedaccess to the requested service, etc, step S7.

In case the OTC received from the user match a verification OTC withinthe small access window, but not the first, most probable verificationOTC, this indicates a slight synchronization deviation. In that case,the synchronization data held by the authentication manager could beautomatically adjusted in accordance with the synchronization data onthe user side. Thus, an automatic re-synchronization is achieved.

If the chosen verification OTC(s) and the OTC received do not match,this indicates a too large synchronization deviation, or an erroneousOTC entry. In this case, at least a part of the remaining sequence ofverification OTCs is searched for a verification OTC matching the OTCreceived from the user, step S8. The remaining sequence comprises thewhole sequence, i.e. the whole big window, except the chosen OTC(s),i.e. the small window, already being evaluated.

In case such a matching verification OTC is identified, step S9,another, second OTC is required from the user, step S11. For example, arequest could be presented to the user in writing through the inputdevice interface, such as “Error OTC, please enter a new OTC”. Thesecond OTC received from the user, step S12, is then compared with theOTC of the verification OTC sequence being subsequent to the identifiedmatching verification OTC, step S13. In case the first and second OTCsprovided by the user are found to be sequential, the user isauthenticated to the system, step S15.

Hereby, the whole sequence forms the big window for access, and thesmall access window discussed previously forms a part of this bigwindow. If the OTC provided by the user is within the small window, theuser is directly authenticated and granted access to the system. If theprovided OTC is outside the small window but within the big window, theauthentication manager saves the first OTC, and a second OTC is requiredfrom the user. If the new, second OTC and the first OTC are in sequence,the end user will be authenticated, and admitted access to the systemand the requested service.

In case of a second match authenticating the user to the system thisindicates a synchronization deviation. In that case, the synchronizationdata held by the authentication manager could be automatically adjustedin accordance with the synchronization data on the user side. Thus, anautomatic re-synchronization is achieved.

Preferably, such an automatic re-synchronization is made every time auser is successfully authenticated, regardless of the way theauthentication was achieved, i.e. the number of OTCs entered, the testsmade on the received OTCs, etc.

If the second OTC supplied by the user does not match the subsequentverification OTC in the authentication manager the user could beregarded as unauthorized, and denied further access to the system and/orthe requested service, step S15. Alternatively, more cumbersomeverification and synchronization processes may be used at this stage.Such more rigid and complex processes are per se well known, and willnot be discussed further.

The system may also comprise encryption and decryption devices. In thatcase, at least part of the communication between the input device andthe authentication manager could be encrypted, whereby the securitylevel is increased even further.

Advantageously, the OTC generation unit possessed by the user could beof the type where a number of different sets of personalizinginformation could be used for generation of different OTCs for a numberof different authentication managers and/or service providers. Such acase enables a user to use one and the same authentication arrangementwhen making transactions with different authentication managers andservice providers.

A second embodiment of the invention will now be discussed withreference to FIG. 3. In this regard it is to be understood that allaspects discussed above in relation to the first embodiment also areapplicable for this second embodiment, unless anything else isexplicitly stated. Further, the same reference numerals are used foridentical or similar steps.

In the method according to the second embodiment a first OTC is firstrequested and analyzed in step S1-S6. In case of a non-match, i.e. whenthe received OTC is not found in the small window, a new OTC isimmediately requested while storing the previously entered OTC, stepS11′.

A new OTC is then generated, step S12′, and is, when received, comparedwith the small access window in the same way as the previous comparison,step S5′. In case of a match for the newly received OTC, step S6′,authentication is granted, step S7′. Hereby, cases such as when thefirst OTC has been entered erroneously, errors has occurred due totransmission problems etc, are taken care of, since the same problem isunlikely to happen twice in a row.

However, in case the newly received OTC is found not be within the smallaccess window in step S6′, the newly received OTC and the previouslyreceived OTC are evaluated based on match within the large window, and apossible sequentiallity. This is tested in step S13′ in a similar way asdescribed above. In case the OTCs are in sequence in the large window,step S14′, authentication is granted, step S15.

In case the OTCs are not in sequence and/or not in the large window,authentication may be denied. However, it is also possible to try oncemore, step S17, and request a new OTC and test it the same way asbefore, i.e. repeat the process from step S11′ and forward. In thiscase, the sequentiallity of the OTCs may be tested in different ways,but preferably the latest received OTC is tested against the one or twoOTCs received before that. Preferably at least one repetition is grantedin step S17, whereby the user will be permitted to enter at least threedifferent OTCs before the process is interrupted and authentication isdenied, step S16.

As already discussed, the authentication process may proceed after theauthentication denial step to more cumbersome verification andsynchronization processes. For example, the user may here be requestedto produce two OTCs at the same time, and said OTCs may be testedagainst the large window and for sequentiallity.

With respect to all aspects of the invention, computer softwareimplementation is obviously preferred. The software of theauthentication manager and service provider may be present in more orless traditional computers, and the software at user side may be withinsmart cards or other portable units having processing-and storage means.

The invention has now been described by way of preferred embodiments.However, many different modifications and alternatives are possible. Forexample, the OTCs may be generated in different ways than bycalculations based on sequence numbers. Several such ways of obtainingOTCs would be available for someone skilled in the art.

1. A method for authenticating a user in a digital communication system,said system comprising at least one input device providing a userinterface to the system, an authentication manager for authenticatingthe user to the system and a communication network connecting said inputdevice and said authentication manager, said method comprising:receiving identification information about the user at saidauthentication manager from said input device; receiving a one time code(OTC) at said authentication manager from said input device;identifying, based on said identification information, a sequence ofverification OTCs associated with said user, said sequence ofverification OTCs forming a big access window; choosing at least one ofthe verification OTCs of said sequence, said chose verification OTCsforming a small access window; and comparing the at least one chosenverification OTC of the small access window and the OTC received fromthe input device, and in case of a match authenticating the user to thesystem; and in case of a non-match: requiring a second OTC from theuser; searching at least a part of the remaining sequence ofverification OTCs of the big access window for two verification OTCs insequence matching the two OTCs received from the user; and in case of amatch authenticating the user to the system.
 2. The method of claim 1,wherein the OTC from the input device is generated by means of an OTCgeneration unit.
 3. The method of claim 2, wherein the generation unitis adapted to generate the OTC based on input provided by a smart cardheld by the user.
 4. The method of claim 2, wherein the OTC generationunit calculates the OTC based on synchronization data.
 5. The method ofclaim 4, wherein the synchronization data is one of a sequence number ora time value.
 6. The method of claim 4, wherein the step of choosing theverification OTCs is made based on verification synchronization dataheld by the authentication manager.
 7. The method of claim 6, wherein incase of a second match authenticating the user to the system, theverification synchronization data is subsequently updated in accordancewith the identified matching verification OTCs.
 8. The method of claim1, wherein the step of identifying a sequence of verification OTCsassociated with said user, comprises the step of calculating a sequenceof OTCs.
 9. The method of claim 1, wherein the step of identifying asequence of verification OTCs associated with said user, comprises thestep of retrieving a sequence of pre-stored OTCs.
 10. The method ofclaim 1, wherein the OTCs are non-recurring strings of characters. 11.The method of claim 1, wherein the identification information comprisesan identification code associated with the user.
 12. The method of claim1, wherein at least part of the communication between the input deviceand the authentication manager is encrypted.
 13. The method of claim 1,wherein before the step of searching at least a part of the remainingsequence of verification OTCs, it further comprises the step ofcomparing the at least one chosen verification OTC and the second OTCreceived from the input device, and in case of a match authenticatingthe user to the system.
 14. An authentication system comprising: atleast one input device providing a user interface to the system; anauthentication manager for authenticating the user to the system; and acommunication network connecting said input device and saidauthentication manager; said authentication manager being configured toreceive identification information about the user at said authenticationmanager from said input device; receive a one time code (OTC) at saidauthentication manager from said input device; identify, based on saididentification information, a sequence of verification OTCs associatedwith said user, said sequence of verification OTCs forming a big accesswindow; choose at least one of the verification OTCs of said sequence,said chosen verification OTCs forming a small access window; and comparethe at least one chosen verification OTC of the small access window andthe OTC received from the input device, and in case of a matchauthenticate the user to the system; and in case of a non-match: requirea second OTC from the user; search at least a part of the remainingsequence of verification OTCs of the big access window for twoverification OTCs in sequence matching the two OTCs received from theuser, and in case of a match authenticate the user to the system.